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Abstract 

To be usable in practice, interactive theorem provers need to pro¬ 
vide convenient and efficient means of writing expressions, definitions, 
and proofs. This involves inferring information that is often left implicit 
in an ordinary mathematical text, and resolving ambiguities in mathemat¬ 
ical expressions. We refer to the process of passing from a quasi-formal 
and partially-specified expression to a completely precise formal one as 
elaboration. We describe an elaboration algorithm for dependent type 
theory that has been implemented in the Lean theorem prover. Lean’s 
elaborator supports higher-order unification, type class inference, ad hoc 
overloading, insertion of coercions, the use of tactics, and the computa¬ 
tional reduction of terms. The interactions between these components are 
subtle and complex, and the elaboration algorithm has been carefully de¬ 
signed to balance efficiency and usability. We describe the central design 
goals, and the means by which they are achieved. 


1 Introduction 

Just as programming languages run the spectrum from untyped languages like 
Lisp to strongly-typed functional programming languages like Haskell and ML, 
foundational systems for mathematics exhibit a range of diversity, from the 
untyped language of set theory to simple type theory and various versions of 
dependent type theory. Having a strongly typed language allows the user to 
convey the intent of an expression more compactly and efficiently, since a good 
deal of information can be inferred from type constraints. Moreover, a type 
discipline catches routine errors quickly and flags them in informative ways. 
But there is a downside: as we increasingly rely on types to serve our needs, the 
computational support that is needed to make sense of expressions in efficient 
and predictable ways becomes increasingly subtle and complex. 

Our goal here is to describe the elaboration algorithm used in a new inter¬ 
active theorem prover, Lean PM- Lean is based on an expressive dependent 
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type theory, allowing us to use a single language to define datatypes, mathemat¬ 
ical objects, and functions, and also to express assertions and write proofs, in 
accordance with the propositions-as-types paradigm. Thus, filling in the details 
of a function definition and ensuring it is type correct is no different from filling 
in the details of a proof and checking that it establishes the desired conclusion. 

The elaboration algorithm that we describe employs nonchronological back¬ 
tracking, as well as heuristics for unfolding defined constants that are very effec¬ 
tive in practice. Elaboration algorithms for dependent type theory are not well 
documented in the literature, making the practice something of a dark art. We 
therefore also hope to fill an expository gap, by describing the problem clearly 
and presenting one solution. 

Lean’s elaborator is quite powerful. It solves not only first-order unification 
problems, but nontrivial higher-order unification problems as well. It supports 
the computational interpretation of terms in dependent type theory, reducing 
expressions as necessary in the elaboration process. It supports ad hoc over¬ 
loading of constants, and it can insert coercions automatically. It supports 
a mechanism for type class inference in a manner that is integrated with the 
other components of the elaboration procedure. It also supports interaction 
with built-in and user-defined tactics. The interaction between the components 
we have just enumerated is subtle and complex, and many pragmatic design 
choices were made to attain efficience and usability. 

We start in Section [2] with an overview of the task of the elaborator, focusing 
on its outward effects. In other words, we try to convey a sense of what the 
elaborator is supposed to do. In Section [3l we explain the algorithm that is 
used to achieve the desired results. We describe related work and draw some 
conclusions in Section 0] Lean is an open-source project, and the source code is 
freely available onlineljj Many of the features discussed below are described in 
greater detail in a tutorial introduction to Lean [4]. 

2 The elaboration task 

What makes dependent type theory “dependent” is that types can depend on 
elements of other types. Within the language, types themselves are terms, and 
a function can return a type just as another function may return a natural num¬ 
ber. Lean’s standard library is based on a version of the Calculus of Inductive 
Constructions with Universes [9l l24lH8] . as are formal developments in Coq (6j 
and Matita [3]. We assume some familiarity with dependent type theory, and 
provide only a brief overview here. 

Lean’s core syntax is based on a sequence of non-cumulative type universes 
and FT-types. There is an infinite sequence of type universes Typeo, Typei, 
Type2, ..., and any term t : Type^ is intended to denote a type in the ith 
universe. Each universe is closed under the formation of Ff-types Fix : A, B, 
where A and B are type-valued expressions, and B can depend on x. The idea is 
that fix : A, B denotes the type of functions f that map any element a : A 

1 http://leanprover.github.io 
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to an element of B [a/x] . When x does not appear in B, the type Fix : A, B is 
written A —> B and denotes the usual non-dependent function space. 

Lean’s kernel can be instantiated in different ways. In the standard mode, 
Typeo is distinguished by the fact that it is impredicative , which is to say, 
Tlx : A, B is an element of Prop for every B : Prop and every A. Elements 
of Prop are intended to denote propositions. When Fix : A, B is in Prop, it 
can also be written as Vx : A, B, and it is interpreted as the proposition that 
B holds for every element x of A. Given P : Prop, an element t : P can be 
interpreted as a proof of P, under the propositions-as-types correspondence, or 
more simply as “evidence” that P holds. Such a type P is proof-irrelevant , which 
is to say, any two terms s, t : P are treated as definitionally equal by the 
kernel. 

Lean also provides a predicative mode for homotopy type theory, without 
any special treatment of Typeo- The result is a version of Martin-Lof type 
theory [HHH] similar to the one used in Agda [7]. 

In both standard and hott modes, the type universes are non-cumulative. 
They are treated polymorphically, which is to say, there are explicit quantifi¬ 
cations over universes. In practice, users generally write t : Type, leaving it 
to Lean to insert an implicit universe variable and manage universe constraints 
accordingly. 

Extensions to the core type theory inhabit a second layer of the kernel. Both 
modes allow one to form inductive families El, a mechanism that can be used 
to define basic types like nat and bool, and common type-forming operations, 
like Cartesian products, lists, E-types, and so on. Each inductive family dec¬ 
laration generates a recursor (also known as the eliminator). The standard 
mode includes a mechanism for forming quotient types, and the mode for ho¬ 
motopy type theory includes certain higher-inductive types 32]. We need not 
be concerned with the precise details here, except to note that terms in depen¬ 
dent type theory come with a computational interpretation. For example, given 
t : B possibly depending on a variable x : A and s : A, the term (Ax, t) s 
reduces to t [s / x] , the result of replacing x by s in t. Similarly, inductive 
types support definition by recursion; for example, if one defines addition on 
the natural numbers by structural recursion on the second argument, t + 0 
reduces to t . The kernel type checker should identify terms that are equivalent 
under the induced equivalence relation, and, as much as possible, the elaborator 
should take this equivalence into account when inferring missing information. 
We discuss this further in Section [2731 

2.1 Type inference and implicit arguments 

The task of the elaborator, put simply, is to convert a partially specified ex¬ 
pression into a fully specified, type-correct term. For example, in Lean, one can 
define a function do_twi.ce as follows: 

definition do_twice (f : N —> N) (x : N) : N := f (f x) 
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One can omit any two of the three type annotations, leaving it to the elaborator 
to infer the missing information. Inferring types like these can be seen as a 
generalization of the Hindley-Milner algorithm ns ns, which takes an unsigned 
term in the A-calculus and assigns a simple type to it, if one exists. 

When entering a term, a user can leave an argument implicit by inserting an 
underscore, leaving it to the elaborator to infer a suitable value. One can also 
mark function arguments as implicit by declaring them using curly brackets 
when defining the function, to indicate that they should be inferred rather 
than entered explicitly. For example, we can define the append function, which 
concatenates two lists, so that it has the following type: 

append : II {A : Type}, list A — > list A — > list A 

Users can then write append li I2 rather than append A li I2, leaving Lean 
to infer the first argument. 

2.2 Higher-order unification 

Many of the constraint problems that arise in type inference and the synthesis of 
implicit arguments are easily solved using first-order unification. For example, 
suppose a user writes append li I2, where li can be seen to have type list 
T. Temporarily naming the implicit argument to append as ?M, we see that next 
argument to append should have type list ?M. Given that li in fact has type 
list T, we easily infer ?M = T. 

Nevertheless, it is often the case that the elaborator is required to infer an 
element of a IT-type, which constitutes a higher-order unification problem. For 
example, if e : a = b is a proof of the equality of two terms of some type A, 
and H : P is a proof of some expression involving a, then the term subst e H 
denotes a proof of the result of replacing some or all of the occurrences of a 
in P with b. Here, in addition to inferring the type A, we also need to infer an 
expression T : A — >■ Prop denoting the context for the substitution, that is, the 
expression with the property that T a is convertible to P. Such an expression is 
inherently ambiguous; for example, if H has type R (f a a) a, then with subst 
e H the user may have in mind R (f b b) borR (f ab) a or something else, 
and the elaborator has to rely on context and a backtracking search to find an 
interpretation that fits. Similar issues arise with proofs by induction, which 
require the system to infer an induction predicate. 

The need for higher-order unification even arises with common datatypes. 
For example, the type Ex : A, B denotes the type of dependent pairs (a, b), 
where a : A and b : B a. Here B is in general a function A —> Type. In the 
notation (a, b), the arguments A and B are left implicit. The argument A can 
easily be inferred from the type of A, but the type of b will generally be an 
expression that involves a as an argument. In this case, higher-order unification 
is used to infer B. 

Even second-order unification is known to be generally undecidable [13]. 
but the elaborator merely needs to perform well on instances that come up in 
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practice. For example, in Lean, users can import the notation H > H’ for subst 
H H ’. If we have proved 

theorem mul_mod_mul_left {z : N} (x y : N) (zpos : z > 0) : 

(z * x) mod (z * y) = z * (x mod y) 

we can then write 

theorem mul_mod_mul_right (x z y : N) : 

(x * z) mod (y * z) = (x mod y) * z := 

Imul.comm > Imul.comm > Imul.comm > !mul_mod_mul_left 

The proof applies the commutativity of multiplication three times to an appro¬ 
priate instance of the theorem mul_mod_mul_left. (The symbol ! indicates 
that all arguments should be synthesized by the elaborator.) The unifier can 
similarly handle nested inductions and iterated recursion. 

theorem add.comm (n m : N) :n+m=m+n:= 
nat.induction_on m 
(nat.induction_on n rfl 

(take n, assume IH : n = 0 + n, 

show succ n = succ (0 + n), from IH > rfl)) 

— induction step omitted 

Or, in the context of homotopy type theory, where equality proofs are relevant, 
we can write: 

definition concat_assoc (p : x = y) (q : y = z) (r : z = t) : 

p • (q ■ r) = (p ■ q) • r := 
eq.rec_on r (eq.rec_on q idp) 

Here rec_on denotes a form of recursion which, like induction, has to infer the 
relevant predicate. 

We will see below that higher-order unification is a complex process, and 
places a high burden on the elaborator. It should thus be used sparingly. But 
it is often convenient and sometimes unavoidable, so it is important that it can 
be handled by the elaboration algorithm. 

2.3 Computational behavior 

The elaborator should also respect the computational interpretation of terms. 
It should, for instance, recognize the equivalence of the terms (Ax, t) s and 
t [s/x], as well as (s, t).l (denoting the first projection of the pair) and s 
under the relevant reduction rule for pairs. Elements of inductive types also 
have computational behavior; on the natural numbers, 2 + 2 and 4 are both 
definitionally equal to succ (succ (succ (succ 0))),x + 0 is definitionally 
equal to x, and x + 1 is definitionally equal to succ x. The elaborator should 
also support unfolding definitions where necessary: for example, if x - y is 
defined as x + (-y), the elaborator should allow us to use the commutativity 
of addition to rewrite x - y to -y + x. Unfolding definitions and reducing 
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projections is especially crucial when working with algebraic structures, where 
many basic expressions cannot even be seen to be type correct without carrying 
out such reductions. For example, given a : A and b : B a, the left-hand side 
of the expression (a, b) .2 = b has type B ((a, b). 1) and the right-hand side 
has type B a. Both the elaborator and the type checker need to recognize these 
types as the same. 

Determining when to unfold defined constants is a crucial part of the practice 
of theorem proving. It is therefore unsurprising that the naive approach of 
performing all such unfoldings leads to unacceptable performance, and it is 
an important aspect of building a practical elaboration procedure to design 
heuristics that limit unfolding to situations that require it. Lean allows users 
to annotate definitions, providing hints to the elaborator, as follows: 

• An irreducible definition will never be unfolded during higlrer-order uni¬ 
fication (but can still be unfolded in other situations, for example during 
type checking). 

• A reducible definition will be always eligible for unfolding. 

• A semireducible definition can be unfolded during simple decisions and 
won’t be unfolded during complex decisions. 

For example, users can mark definitions which ought to be viewed as abbrevi¬ 
ations as reducible. The meaning of these annotations is discussed further in 
Section 13.31 These annotations are used only by the elaborator; they have no 
bearing at all when it comes to checking the type of a fully elaborated term. As 
a result, the user can modify these annotations at any time, as needed, when 
developing a theory. 

2.4 Type classes 

Lean supports the use of Haskell-style type classes nn. For example, we can 
define a class has_mul A of types A with an associated multiplication as follows: 

structure has_mul [class] (A : Type) := (mul : A —i A —> A) 

In other words, for every type A, has_mul A is a record with one element, 
has_mul.mul, which we should think of as a multiplication operation on A. 
We then define the generic multiplication operation, 

definition mul {A : Type} [s : has_mul A] : A —>■ A —>■ A : = 
has_mul.mul 

and the notation 

infix * := mul 

The square brackets indicate that the argument s is implicit, and that the 
relevant instance of has_mul A should be synthesized by the class inference 
mechanism. We can declare a particular instance as follows: 


6 


definition nat_has_mul [instance] : has_mul nat := 
has_mul.mk nat.mul 

Suppose the user writes s * t, when s is inferred to have type nat. When 
the elaborator is called to solve ?M : has_mul nat, it finds nat_has_mul on a 
stored list of instances, and assigns that to ?M. 

Instance declarations themselves can have implicit class arguments, in which 
case, class inference performs a backward-chaining Prolog-like search. For ex¬ 
ample, we can declare 

structure semigroup [class] (A : Type) extends has_mul A := 
(mul_assoc : Va b c, mul (mul a b) c = mul a (mul be)) 

The structure declaration above automatically declares semigroup to be an 
instance of has_mul, so that if, instead, nat was only declared to be an instance 
of semigroup, class inference could synthesize the instance of has_mul nat in 
two steps. We then get the generic theorem mul.assoc in the same way we 
obtained the generic notation for multiplication. 

We can then go on to define monoids, groups, rings, and commutative ver¬ 
sions. The structure command supports the construction of the algebraic 
hierarchy by allowing the user to extend and merge multiple structures: 

structure group [class] (A : Type) 

extends monoid A, has_inv A := 

(mul_left_inv : Va, mul (inv a) a = one) 

Users can also rename structure components on the fly. In the following example, 
type class inference finds the appropriate inverse and instance of the theorem 
inv_inv when processing eq_inv_of_eq_inv: 

theorem inv_inv {A : Type} [s : group A] (a : A) : 

(a- 1 )" 1 


theorem eq_inv_of_eq_inv {A : Type} [s : group A] {a b : A} 

(H : a = b” 1 ) : b = a -1 := 

by rewrite [H, inv_inv] 

Here, the rewrite tactic replaces a by b” 1 in the goal, and then rewrites 
(b -1 )” 1 to b. Since any group is an instance of a monoid and any monoid 
is an instance of a semigroup, generic theorems about semigroups and monoids 
can be applied to any group. The type class inference is seamless integrated in 
all proof procedures implemented in Lean. We remark that the theorem above 
can be proved without any user guidance using these procedures. 

We can also declare so called fully bundled structures in the style of the 
Mathematical Components library jT2]. For example: 

structure Group := (carrier : Type) (struct : group carrier) 

attribute Group.carrier [coercion] 
attribute Group.struct [instance] 
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This means that whenever we have G : Group, we can write g : G, and G is 
coerced to its carrier type. And whenever we have g : carrier G, type class 
resolution can infer that struct G is the relevant group structure on carrier 

G. 

In Lean, type classes can be used to infer not only notation and generic 
facts, but fairly complex data. For example, in the standard library, we define 
the class of propositions that are decidable: 

inductive decidable [class] (p : Prop) : Type := 

I ini : p —>• decidable p 
I inr : -ip —>• decidable p 

Logically speaking, since decidable p lives in Type rather than Prop, having an 
element t : decidable p is more informative than having an element t : p 
V ^p; it enables us to define values of an arbitrary type depending on the truth 
value of p. This distinction is only useful in constructive mathematics, because 
classically every proposition is decidable. But the decidable class allows for 
a smooth transition between constructive and classical logic, allowing classical 
reasoning in suitable constructive settings as well. It is especially relevant for 
users interested in defining computable functions. In Lean, (if c then t else 
e) is notation for (ite c t e), where ite is defined as: 

definition ite (c : Prop) [H : decidable c] {A : Type} 

(t e : A) : A := 

decidable.rec_on H (A He, t) (A Hnc, e) 

Note that the implicit argument H is automatically synthesized by type class 
inference. Moreover, the expression if c then t else e computes whenever 
c is a decidable proposition. 

For example, we can prove, constructively, that equality on the natural num¬ 
bers is decidable: 

nat.decidable_eq [instance] : V x y : nat, decidable (x = y) 

We can do the same for inequality relations on nat, and moreover show that 
decidability is preserved under boolean operations and bounded quantification. 
We moreover make the following definitions: 

definition is_true (c : Prop) [H : decidable c] : Prop := 
if c then true else false 

definition of_is_true {c : Prop} [Hi : decidable c] 

(H 2 : is_true c) : c := 
decidable.rec_on Hi (A He, He) 

(A Hnc, Ifalse.rec (if_neg Hnc > H 2 )) 

notation 1 dec_trivial‘ := of_is_true trivial 

What is going on here is subtle. The expression is_true c infers a decision 
procedure for c, and returns either true or false. Assuming H 2 : is_true c, 


of _is_true H 2 is a proof of c. But if is_true c evaluates to true, it has the 
canonical proof trivial. Thus, given a proposition c, the notation dec_trivial 
does the following: 

• infers a decision procedure for c, and 

• tries to use trivial to prove is_true c. 

If it succeeds — that is, if the resulting term type checks — the result is a proof 
of c. 

With these definitions, we can write the following proof: 

example : V x : nat, x < 10 -4 x / 10 A x < 12 := dec_trivial 

Type class resolution infers the decision procedure for the proposition in ques¬ 
tion, and computational reduction evaluates it. Problems like this can appear 
anywhere in a proof or an expression, and type class inference will solve them 
at appropriate times within the elaboration process. 

2.5 Overloading 

We have seen that the standard library relies on type class inference to support 
the use arithmetic operations like + and * for different number classes. This 
is sometimes known as parametric polymorphism. Lean also supports ad hoc 
polymorphism by allowing us to overload identifiers and notation. For example, 
the notation ++ is used for concatenation of both lists and tuples: 

import data.list data.tuple 
open list tuple 

variables (A : Type) (m n : N) 

variables (v : tuple Am) (w : tuple An) (s t : list A) 

check s ++ t 

check v ++ w 

Where it is necessary to disambiguate, Lean allows us to precede an expression 
with the notation #<namespace>, to specify the namespace in which notation is 
to be interpreted. 

check A x y, (#list x + y) 

check A x y, (#tuples x + y) 

We can also overload identifiers. Every identifier in Lean has a full name 
that is unique, but identifiers can be grouped into namespaces, and opening the 
namespace produces a shorter alias. For example, if we define f 00 in namepsaces 
a and b, we obtain identifiers named a. foo and b. f 00 respectively. If we open 
both namespaces, however, the alias foo is an overloaded reference to both, 
leaving the elaborator to resolve the ambiguity. 
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Ad hoc overloading is more flexible than type class overloading, in that the 
overloaded constants can denote entirely different kinds of objects. It adds 
ambiguity and choice points to the elaboration process, and should therefore 
be used sparingly. But it is often useful, especially when we want to reuse 
notation for expressions that do not have the same shape. For example, in 
the Lean standard library, we use -1 above to denote the inverse function for 
algebraic structures that support it, as well as for the symmetry operation for 
equalities. It can also be used to invert bijections, used group isomorphisms, ring 
isomorphisms, isomorphisms in a category, or equivalences between categories. 

2.6 Coercions 

The treatment of coercions in Lean is as one would expect. One can, for example, 
coerce a bool to a nat and a nat to an int, and Lean will insert coercions in 
list expressions [n, i, m, j] and [i, n, j, m] when n and m have type nat 
and i and j have type int. One can also coerce axiomatic structures, so that 
the user can provide a group as input anywhere a semigroup is expected. One 
can also coerce from a suitable family of types to Type or to a fl-type. 

In fact, just as in Coq, Lean allows us to declare three kinds of coercions: 

• from a family of types to another family of types 

• from a family of types to the class of sorts 

• from a family of types to the class of function types 

The first kind of coercion allows us to view any element of a member of the 
source family as an element of a corresponding member of the target family. 
The second kind of coercion allows us to view any element of a member of the 
source family as a type. The third kind of coercion allows us to view any element 
of the source family as a function. For details, see [I]. 

2.7 Tactics and structuring mechanisms 

Finally, definitions and proofs can invoke tactics, that is, user-defined or built- 
in proof-finding procedures that construct various subterms. The constraint 
solver described in this paper invokes user provided tactics to construct terms 
that cannot be synthesized by solving unification constraints and type class 
resolution. Lean’s tactic language is similar to those found in other LCF-style 
theorem provers. Describing the tactic language here would take us too far 
afield; we only wish to point out that our implementation makes the use of 
tactics continuous with the act of writing terms. Anywhere a term is expected, 
a user can used the keywords begin and end to enter a tactic block: 

theorem test (p q : Prop) (Hp : p) (Hq : q) : p A q A p := 
begin 

apply and. intro, 
exact Hp, 
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apply and. intro, 
exact Hq, 
exact Hp 
end 

One-line tactic proofs can be specified with the keyword by: 

theorem test (p q : Prop) (Hp : p) (Hq : q) : p A q A p := 
by apply (and. intro Hp); exact (and. intro Hq Hp) 

Conversely, when in tactic mode, one can use the exact tactic to specify an 
explicit term, as in the example above. The keywords have and show make it 
possible to do that in an elegant and structured way. 

theorem card_image_eq_of_inj_on {f : A —> B} {s : finset A} 

(HI : inj_on f (ts s)) : 
card (image f s) = card s := 

begin 

induction s with at H IH, 

{rewrite [card_empty]}, 

{have H2 : ts t C ts (insert a t) , 

by rewrite [-subset_eq_to_set_subset]; 
apply subset_insert, 
have H3 : card (image f t) = card t, 

from IH (inj_on_of_inj_on_of_subset HI H2), 
have H4 : f a ^ image f t, 

from ..., — proof suppressed 
show card (image f (insert a t)) = card (insert a t), 
from ... — proof suppressed} 

end 

Thus one can pass freely between the two modes. This yields a tradeoff between 
two different strategies for elaboration: tactics build an expression using local 
information in a surgical way, whereas the elaborator solves constraints involving 
global information, spread out across the entire term. 

The availability of tactic mode also provides a convenient way of sectioning 
long proof terms: the construct proof t qed is syntactic sugar for by+ exact 
t. Including this in a long proof terms forces the elaborator to process the 
surrounding expression independent of t, and then process t, separately, using 
information from the surrounding term. Thus we can treat the processing of a 
long proof as one large elaboration problem or the composition of smaller ones, 
balancing the advantages of the local and global approaches in a convenient and 
flexible way. 

2.8 Combining the various components 

Any given definition or theorem in Lean can draw on many of the features just 
described. Consider the following, which defines the composition of two natural 
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transformations between functors 
transformation): 

variables -fC D : Category} 

definition nt_compose (77 : 

natural_transformation.mk 
(take a, 77 a o 9 a) 

(take a b f, calc 
H f o (77 a o 9 a) = (H 

... = (77 
. . . = i) b o (G f o S a) : assoc 

. .. = 77 b o (0 b o F f) : naturality 

. . . = (77 b o 9 b) o F f : assoc) 

Here the functors F, G, and H are coerced to their action on morphisms, and 

the natural transformations 77 and 9 are coerced to their first component. The 
composition symbol o for functions is overloaded to denote composition of mor¬ 
phisms as well, and type class inference infers the category in which the compo¬ 
sition takes place. The appropriate substitution contexts in the calculation are 
inferred, as are the arguments to the theorems that are invoked. 

The interactions between the components of the elaboration task are subtle, 
and the challenge is to deal with them all at the same time. A definition or 
proof may give rise to hundreds of constraints requiring a mixture of higher- 
order unification, disambiguation of overloaded symbols, insertion of coercions, 
type class inference, and computational reduction. The net effect is then a 
difficult constraint-solving problem with a combinatorial explosion of options. 
Lean’s elaborator manages to solve such problems, and it is quite fast. (See, for 
example, the data presented at the end of Section Eh3l ) In the next section, we 
explain how the elaborator processes the constraints and navigates the search 
space in an effort to balance completeness and efficiency. 

3 The elaboration procedure 

3.1 Overview 

Section [2] describes what we want the elaboration algorithm to do. It needs to 
infer types and implicit arguments in expressions, including sometimes higher- 
order functions and predicates. It needs to support type class inference that is 
robust enough to work with structures in an algebraic hierachy an a uniform 
and convenient way. It needs to dismabiguate overloaded notation and iden¬ 
tifiers, and it needs to insert coercions where appropriate. Moreover, it needs 
to respect the computational behavior of expressions while performing all these 
tasks, since, in general, the constraints can only be solved up to equivalence of 
terms. The goal of this section is to describe an algorithm that does this. 

The task of Lean’s parser, which we do not describe here, is to convert a 
user’s input to a preterm , a formal but incomplete reflection of that input. The 


(and establishes that it is, indeed, a natural 
{F G H : C =>• D} 

G =>■ H) (9 : F =>• G) : F =>■ H : = 


f o 77 a) o 9 a : assoc 
boGf) o 9 a. : naturality 


12 



process for getting from a preterm to a fully elaborated term has two main 
steps: preprocessing and constraint resolution. The preprocessing phase takes 
a preterm and creates a partially specified term, with “holes,” or metavari¬ 
ables, representing the information that needs to be inferred. At the same time, 
the preprocesor generates a list of constraints that these metavariables need to 
satisfy. Some of the constraints are unification constraints , for example, the 
constraint that the type of an argument to a function matches the function’s 
argument type. Others are choice constraints, for example, that an inferred 
value is among a finite set of possible overloads. Finally, after all constraints 
have been solved, Lean invokes the tactic blocks associated with the remaining 
holes to produce the terms necessary to fill them. This is a recursive procedure 
because some tactics may contain nested preterms that must be also elaborated, 
and these preterms may additional tactic blocks, and so on. 

The constraint resolution phase aims to find a consistent solution to all the 
unification and choice constraints. Heuristically, “straightforward” constraints 
should be solved first, providing useful information to guide the rest of the 
search. Choice points result in backtracking, which needs to be handled carefully 
to avoid duplication of work. Failures need to be carefully tracked in order to 
provide informative error messages to the user. 

The simple division into the preprocessing phase and constraint resolution 
phase is slightly too simplistic: even the preprocessing phase has to process 
and simplify constraints, in order to detect the possibility of inserting a coer¬ 
cion. Thus both phases make use of a constraint simplification procedure that 
performs preliminary reductions. 

We spell out the details below. Sections 13.21 and 13.31 describe the main 
data structures and some of the support functions used by the algorithm, and 
Section [33] describes the constraint simplification procedure. The preprocessing 
step is described in Section 13.51 and the constraint solving procedure, which is 
both the heart of the elaboration algorithm and the most complex component, 
is described in Sections 13.61 and 1571 

3.2 Main data structures 

In this section, we describe the term representation and the main data structures 
used in our elaboration procedure. We assume the term language is a dependent 
A-calculus in which terms are described by the following grammar: 

t, s = £ | x | / | ?m | Type u \ t s \ Xx : s,t \ Wx : s, t 


where 

• £ a free variable (also called a local constant) 

• x is a bound variable 

• / is a constant (parametrized by a list of universe terms) 

• ?m is a metavariable 
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• u is a universe term 


We adopt a locally nameless variable binding style: free variables have a 
unique identifier and a type, while bound variables are simply represented by a 
number, a de Bruijn index. We store the type with each free variable, thereby 
removing the need to carry around contexts in the type checker and normal- 
izer. As described in PH , this representation style simplifies the implementation 
considerably, as it minimizes the number of places where explicit calculations 
with de Bruijn indices must be performed. We use the notation t[x := s] to 
represent the substitution of x for s in t, where a; is a bound variable, free vari¬ 
able, or metavariable. When a; is a bound variable, the operation also lowers 
all bound variables with index greater than x. We use t to denote sequence of 
terms t\ . .. t n , and x : A for the telescope (aq : A\) ... (x n : A n ), where Ai 
may depend on Xj for j < i. 

While the locally nameless approach simplifies many aspects of the code, the 
operations of abstracting and instantiating variables can be costly. Fortunately, 
we found a simple optimization that completely eliminates any performance 
concerns. The problem, and our solution, are described at the end of Section EOl 

An environment stores a sequence of declarations. The Lean kernel supports 
three different kinds of declarations: axioms, definitions and inductive families. 
Each has a unique identifier, and can be parametrized by a sequence of universe 
parameters. Every axiom has a type, and every definition has a type and a 
value. A constant is just a reference to a declaration. 

A user’s input to the elaborator can generally be viewed as partial construc¬ 
tions , i.e., constructions containing holes that must be filled by the system. 
Internally, each hole is represented by a metavariable. Each metavariable has a 
unique identifier and a type. The main operation on metavariables is instantia¬ 
tion. In our implementation, only closed terms can be assigned to metavari¬ 
ables. This design decision guarantees that operations such as /3-reduction 
and metavariable instantiation commute. Since only closed terms can be as¬ 
signed to metavariables, on creation a metavariable is applied to the variables 
in the context where it appears. For example, we encode a hole in the context 
{x : A) (y : B) as ?m x y, where ?m is a fresh metavariable. The type of 1m is 
TT(x : A) (y : B), C, where C is the expected type for the hole at that position. 
If the expected type is also unknown at preprocessing time, we create another 
fresh metavariable ?mj : TT(:r : A) (y : 13), Type lu, where lu is a fresh universe 
metavariable. This gives us ?m : n(x : A) (y : B),?mt x y. We say a term is 
fully elaborated if it does not contain metavariables. 

We say a term is /3-reducible if it is of the form ( Xx : A, s)t, and i-reducible 
if it is of the form C.rec s (C.mk; r) t, where C.rec is the recursor/eliminator 
for an inductive datatype C. Here, the sequence s represents the parameters, 
minor premises and indices, and (C.mk., r) is the main premise (where C.mk,; 
is the i-th constructor of C). The function reduce^, s applies head ft and i 
reduction to s. We say a term t is stuck if computation cannot occur without 
instantiating a metavariable ?m, where (?m s) is a sub-term of t. In that case, 
we say (?m s) is the reason for t being stuck. More formally, a term is stuck 
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when the head symbol is a metavariable (i.e., it is of the form 7m s), or it is a 
recursor application where the main premise is stuck. We say the first case is a 
stuck application, and the second a stuck recursor. 

During the preprocessing step, unification and choice constraints are gener¬ 
ated. Unification constraints are used to enforce typing constraints, and choice 
constraints are for overloading, coercion resolution, and triggering the type class 
mechanism. 

A unification constraint t m s is annotated with a justification, which rep¬ 
resent the facts and assumptions that gave rise to the constraint. Justifications 
are used to assist the generation of error messages when a term fails to be elabo¬ 
rated, and to implement non-chronological backtracking [25j . Non-chronological 
backtracking allows exploring the (possibly infinite) tree of potential solutions 
more efficiently, by eliminating branches which we know cannot possibly contain 
an actual solution. 

There are three kinds of justifications: asserted, assumption and join. An 
asserted justification is used to annotate constraints generated during the pre¬ 
processing phase. Whenever the solver has to perform a choice (also known as 
a case split), it annotates each choice with a fresh assumption. A join justifi¬ 
cation j i cxi j 2 represents the “union” of the justifications j i and j 2 . We use 
(t ss s, j) to denote the unification constraint justified by j. A substitution 
is a finite collection of assignments from metavariables to pairs (t,j), written 
7m (t,j), where t is a closed term and j is a justification for the assignment. 
Assignments are generated when solving unification constraints. For example, 
the constraint (7m « t, j) is solved by adding the assignment 7m (t,j). 
Whenever we apply a substitution we use a join justification to track its effect. 
For example, the result of applying the assignment 7m ( t,j m ) over the con¬ 
straint (r « s, j) is the new constraint (r[?m := t] « s[7m := t], j xij m ). We 
also use (s ~ t, j i) ixi j 2 to denote the constraint ( s « t, j\ cxi j 2 ). Moreover, if 
a is a list of constraints [c\,... ,c n \, a txi j is [ c\ ixi j,..., c n cxi j]. 

A choice constraint is of the form (7m t :t in f,j), where: 

• 7m is a metavariable, 

• t are free variables representing the context where 7m was created, 

• t is the type of 7m i, and 

• / is a procedure that, given the term 7m l, its type t, and a substitu¬ 
tion, produces a (possibly unbounded) stream of constraints representing 
possible ways of synthesizing 7m, and a justification j. 

Note that each alternative is itself a list of constraints, and is not necessarily 
just a single unification constraint. 

Whereas some constraints should be solved eagerly, other constraints should 
be solved only when there is sufficient information to process them in a reliable 
way. To that end, a choice constraint 7m i : t in / may be marked as onde- 
mand. When the flag ondemand is set, the constraint solver will try to invoke 
function / only after all metavariables in t have been instantiated. We say a 
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ondemand choice constraint is ready when t does not contain metavariables, 
and postponed otherwise. We will later describe how this feature is used to 
implement the type class mechanism and coercions. If a choice constraint is not 
marked as ondemand , we say it is a regular choice constraint. We use regular 
choice constraints to specify overloaded symbols. The result of applying the 
assignment ?m (s,j m ) over the choice constraint (In £ : t in f,j) is the new 
constraint (?n £ : f[?m := s] in f,j xi j m ). We also use the notation cm j 
when c is a choice constraint. 

3.3 Support functions 

In this section, we describe some auxiliary functions that are used throughout 
the elaboration algorithm. 

The function typeof r returns the inferred type of a term r, where r may 
contain metavariables. Specifically, it returns a pair (f, S) where t is the type 
of r and S' is a set of constraints on the metavariables. If r does not contain 
metavariables, then S is empty. 

Given (£\ : A\)... (t n : A n ), the operation abstract^ [£i... £ n } t returns 
A(^l . A\) ... ( X n . A n \£i . — X\ , . . . , £ n —± .— l]) > ■— *^1) • • * j fn ■ — ^n\ 

We also have abstractor, the equivalent operation for IT-abstraction. 

The function unfold (/ t\...t n ) applies a d-reduction, i.e. it unfolds the 
definition of constant /. In practice, however, it is not feasible to apply 6- 
reduction to all constants in a constraint solving problem. To cope with this 
performance issue, we allow the user to annotate definitions with the hints ir¬ 
reducible , semireducible or reducible , as described in Section liOl Recall that an 
irreducible definition is never unfolded by the constraint solver, while a semire¬ 
ducible or reducible definition may be unfolded or not depending on the con¬ 
straint being solved. Roughly, a semireducible definition is unfolded only if the 
decision to unfold is “simple,” which is to say, if the unfolding does not require 
the procedure to consider an extra case split. When a decision is not simple, 
the unfolding produces at least one extra case, and consequently increases the 
search space. When no annotation is provided, the system assumes the defini¬ 
tion is semireducible. Note that when the kernel type checks fully elaborated 
definitions, these annotations are ignored; they are only relevant during the 
elaboration process. 

The function whnf r returns a pair (w, S) where w is a term convertible 
to r that is in weak head normal form (whnf) or is stuck, and S' is a set of 
unification constraints. (In this paper, we can assume the set S returned by 
whnf is always empty. In our implementation, constraints in S arise because 
the elimination rule for equality has extra computational reductions when proof 
irrelevance is enabled, corresponding to Streicher’s axiom K [29]. Specifically, 
given Hi : a = a, the term eq.rec A a C a H 2 Hi reduces to H 2 even when 
Hi is not the constructor eq.refl A a, where eq.rec is the recursor for the 
Leibniz equality. To that end, the elaborator has to infer the type of Hi, which 


16 


can give rise to unification constraints.) The function whnf does not unfold 
irreducible definitions, and during type class resolution, it also does not unfold 
semireducible ones. 

The procedure error j throws an exception tagged with a justification j. 

Finally, the function ensurefun s j ensures that s has a function type. 
Specifically, it infers the type t of s (using typeof) and then reduces t to t' 
in weak head normal form. If t' is a TT-term, then it returns t' and any new 
unification constraints. If t' is not a IT-term and is not stuck, then it generates an 
error with justification j. Otherwise, if ?m s is the reason that t' is stuck, where 
??n : (T\x : A , B), we create two fresh metavariables: ?toi : (Tlx : A , Type ?rti) 
and ?m 2 : (TT(a; : A) (y : lm\ x ), Type ?u 2 ), and the new constraint 

(t « (Tlx : ?TOi s , 1m 2 s x ), j). 

This ensures that s has a function type, and defers the problem of figuring out 
what that type is. 

Recall that we use the local nameless approach for representing terms, in 
which free variables have a unique identifier and a type, while bound variables 
are represented by a de Bruijn index. We say a term t has a dangling bound 
variable if there is a bound variable in t that is not in the scope of any A/TT- 
expression binding it. For example, the A-expression Ax : Type, f x (g x) has 
no dangling bound variables, but x is a dangling bound variable in / x (g x). 
In the locally nameless approach, all major operations (such as type inference, 
normalization, and unification) assume there are no dangling bound variables, 
that is, no bound variables that “point out of the scope.” This invariant is 
enforced by replacing bound variables with fresh free variables whenever we 
visit the body of a A/TT-expression. In the lambda expression above, we would 
replace x in / x ( g x) with the free variable t : Type. This operation is called 
instantiate in m- The operation abstract l t is the inverse; it replaces the 
free variable t in t with the bound variable with de Bruijn index 0. These two 
operations are essentially the only ones that have to deal with de Bruijn indices. 

Although the locally nameless approach greatly simplifies the implementa¬ 
tion effort, there is a performance penalty. Given a term t of size n with m 
binders, it takes 0(nm) time to visit t while making sure there are no dangling 
bound variables. In m, the authors suggest that this cost can be minimized by 
generalizing abstract and instantiate to process sequences of free and bound 
variables. This optimization is particularly effective when visiting terms con¬ 
taining several consecutive binders, such as Axq : Ai, AX 2 : A 2 ,, Xx n : A n , t. 
Nonetheless, we observed that these two operations were still a performance 
bottleneck for several files in the Lean standard library. We have addressed 
this problem using a very simple complementary optimization. For each term 
t , we store a bound B such that all de Bruijn indices occurring in t are in the 
range [0,U). This bound can easily be computed when we create new terms: 
the bound for the de Bruijn variable with index n is n + 1, and given terms t 
and s with bounds B t and B s respectively, the bound for the application (t s) is 
ma x(B t ,B s ), and the bound for (Ax : t, s) is ma x(B tl B s — 1). We use the bound 
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B to optimize the instantiate operation. The idea is simple: B enables us to 
decide quickly whether any subterm contains a bound variable being instanti¬ 
ated or not. If it does not, then our instantiate procedure does not even visit 
the subterm. Similarly, for each term t, we store a bit that is set to “true” if 
and only if t contains a free variable. We use this bit to optimize the abstract 
operation, since it enables us to decide quickly whether a subterm contains a 
free variable. 

These optimizations are crucial to our implementation. The Lean standard 
library currently contains 172 files, and 41,700 lines of Lean code. With the 
optimizations, the whole library can be compiled in 71.06 seconds using an Intel 
Core i7 3.6Ghz processor with 32Gb of memory. Without the optimizations, it 
takes 2,189.97 seconds to compile the same set of files. 

3.4 The constraint simplification procedure 

The preprocessing step and the constraint-solving procedure rely on a constraint- 
simplification procedure, which we now describe. The idea of the simp procedure 
is to decompose all the constraints that can “straightforwardly” be decomposed 
to simpler ones, and to detect quickly any constraints that simply cannot be 
solved. Thus, given a unification constraint, the simp procedure produces a set 
of (potentially) simpler unification constraints or throws an error. Moreover, 
if the input constraint does not contain metavariables, then the result is the 
empty set {} or an error. 

In the pseudocode below, s and t denote arbitrary terms, £ is a free vari¬ 
able, and / and g are constants. The procedure mklocal A creates a fresh 
free variable with type A. To simplify the presentation, we assume there is 
a global unique name generator. The function depth / returns the defini¬ 
tion depth of the constant /, which is equal to 0 if / is not a definition, and 
1 +max{depth g \ g appears in the definition of /} otherwise. To save space, we 
do not list symmetric cases; for example, we present a case for (s « (Ax : B , t), j) 
but not ((Ax : B,t) « s, j). 

simp (t « t, j) = {} 

simp (s « f, j) when s is f3 /(.-reducible = simp (reduce^ s ~ t, j) 

simp (i si... s n « l ti... t n , j) = UHi sim P ( s i ~ **> j) 

simp (/ si... s n « / ti... t n , j) = 

if si... s„ and ti... t n do not contain metavariables then 
simp ((unfold (/ Si ... s„) « unfold (/ ti ... t n ), j )) 
else if / is not reducible then (JjLi si m P (s,: « U, j) 
else {(/ Si.. .s n « / ti. ,.t n , j )} 
simp {f stag t, j) = 

if depth / > depth g and / is not irreducible then 
simp ((unfold (/ s) & g t, j)) 
else if depth / < depth g and g is not irreducible then 
simp ((/ s « unfold (g t ), j}) 

else if depth / = depth g and / and g are not irreducible then 
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simp ((unfold (/ s) ss unfold (g t), j )) 
simp ((Ax : A, s) « (A y : B,t), j) = 

let £ = mklocal A in simp (A « B , j) U simp (s[x := £} ~ t[y := £\, j) 

simp ((TTx : A, s) « (TTy : B, t), j) = 

let £ = mklocal A in simp (A « B , j) U simp (s[x := £] ~ t[y := f], j) 

simp (s « (Ax : B,t), j) = 

let ((TTx : A, C), S) = ensurefun s j in 
simp ((Ax :4,si)a (Ax : -B, t), j) U S 
simp (s « t, j) = 

if s or t is stuck then {(s « t, j)} else error j 

In the actual implementation, we also use a heuristic optimization for the 
case simp (f si... s n ~ f t±.. ,t n , j), where si... s n and fi... t n do not contain 
metavariables, and / is not a projection. In this case, we first try simp (si ~ 
t\, j) ... simp (s n ~ t n , j), and if no error is thrown, we return {}. 

Each unification constraint returned by simp is in one of the following cat¬ 
egories: 

• delta: (/ s sa / t, j). Note that, based on the definition of simp, / must 
be a reducible definition. 

• pattern: (?m £\... £ n « t, j), where £i ,..., £ n are pairwise distinct free 
variables, t only contains free variables in {£ 1 ,... ,£ n j, and ?m does not 
occur in t. 

• quasi-pattern: (?m £\.. .£ n ~ t, j), where all £i,...,£ n are free vari¬ 
ables, but are not pairwise distinct. 

• flex-rigid: (?m si... s n ~ t, j), where at least one of Si,..., s n is not a 
free variable. 

• flex-flex: (?mi s K,lm 2 t, j)- 

• recursor: (t ~ s, j), where t or s is a stuck recursor. 

In the literature, pattern, quasi-pattern, and flex-rigid are simply called 
flex-rigid constraints, and the category pattern corresponds to Miller pat¬ 
terns [22]. Note that flex-flex constraints are badly underconstrained, and we 
typically expect that other constraints will do more to limit the interpretation 
of the metavariables. 

3.5 Preprocessing 

The preprocessor is a recursive procedure that, given a preterm and a context, 
returns a term t (potentially containing metavariables) and a set of unification 
and choice constraints. The basic idea is that if the constraints are solved, 
their solution should contain an assignment for all metavariables in t. The 
preprocessor must carry a context, a list of free variables, to be able to create 
fresh metavariables. This is the only procedure in our implementation that 
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“carries contexts around.” The preprocessor only creates asserted justification 
objects. 

Applications (r s ) are the main source of unification constraints. After a 
preterm p in a context £ is converted into the application (r s), the preprocessor 
uses ensurefun to make sure that the type of r is of the form FTa; : A, H, and 
simp to enforce that the type C of s is convertible to A. If C is not convertible 
to A , the preprocessor checks the database of available coercions. If there is 
a coercion c from C to A , it replaces the application (r s) with (r (c s)). 
If A is stuck, but there are coercions {ci,...,c n } from C, the preprocessor 
creates a fresh metavariable 7m : abstractn £ A, replaces the application with 
(r (7m £)), and creates a ondemand choice constraint (7m £ : A in f,j), where 
the choice function / produces one of the following alternatives s, C\ s, ..., 
c n s. If possible, the solver will only invoke / after all metavariables in A have 
been instantiated. In this ideal situation, / returns at most one solution, and 
no case-analysis is needed. The same process is performed when C is stuck and 
there are coercions to A. We currently do not try to inject coercions when both 
A and C are stuck at preprocessing time. 

As noted in Section [2.61 Lean supports parametric coercions, and coercions 
to sorts and function classes. Ad hoc overloading is also realized using choice 
constraints. The idea is the same, but we create a regular choice constraint, 
where the choice function / produces the different interpretations for the over¬ 
loaded symbol. 

In a context £, a placeholder is simply replaced by ?m £, where 7m is a 
fresh metavariable. 

Finally, to handle implicit arguments, when we infer the type t of a term 
r, if t is of the form Fl{x : A},B, then we create a fresh metavariable 7m : 
abstractn £ A and replace r with the application (r (7m £)). If the implicit 
argument is marked with square brackets to indicate it should be synthesized 
by the type class mechanism, we also create an ondemand choice constraint 
(7m £ : A in f,j), where the choice function / invokes the type class resolution 
procedure. This procedure is essentially a simple A-Prolog interpreter [52], where 
the Horn clauses are the user-declared instances. 

3.6 The constraint solving procedure 

Given a set of constraints, our solver returns a failure, or a substitution S and 
set of flex-flex constraints of the form (?mi s ss?TO2 t, j) such that neither 
?toi nor ?m 2 are assigned in S. In other words, it is required to solve all the 
constraints that are presented to it, but it does not assign metavariables whose 
solutions are underconstrained. 

The solver uses the following data structures: 

• a priority queue Q of constraints, 

• a mapping U of metavariables to constraints, 

• a substitution S, and 
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• a case split stack C. 

To simplify the presentation, we assume Q, U, S and C are global variables. 

The priorities for the Q are computed using the following total order, -<, on 
constraint categories: 

pattern -< ready -< regular -< delta -< quasi-pattern -< 
flex-rigid -< recursor -< postponed -< flex-flex 

Recall that ready, regular, and postponed are all choice constraints. If two 
constraints are in the same category, we use the first-in-first-out method. 

The mapping U works as follows: for each metavariable ?m, U[?m\ is the 
finite subset of the constraints in Q such that for each c in U[tm], c is a uni¬ 
fication constraint stuck because of ?m, or c is an ondemand choice constraint 
(In £ : t in f,j) and ?m occurs in t. The set U[?m\ contains the set of con¬ 
straints that need to be (re-)visited whenever ?m is assigned. We remark that 
a unification constraint in E/[?ro] may become simpler after we replace ?m with 
its assignment. Similarly, an ondemand choice constraint (?m £ : t in f,j) in 
U[7m] is ready to be processed when all metavariables in t have been assigned. 

Given a set of constraints s, for each constraint c in s, the procedure visit s 
simply invokes visiteq c if c is a unification constraint, and visitchoice c 
otherwise. The procedure visiteq (r ~ s, j) is defined as follows: 

if r or s is stuck by some ?m and ?m e-t ( t,j m ) in S then 
visit (simp (r[?m := t] « s[?m := t ], j IX j m )) 
else if the constraint is a pattern (?m £ ~ t, j) then 
add the assignment ?m K > ((abstract}, £ t),j) to S 
for each c in U[?m\, visit (c) 
else update U, and insert constraint into Q 

The procedure visitchoice (In £ : t in /, j) just substitutes any assigned 
metavariable ?m occurring in t , updates U, and inserts the constraint into Q. 
Note that, we never insert pattern constraints into Q. 

To implement a backtracking search, we need a mechanism for restoring the 
state of the solver during a backtrack operation. We use a very simple approach 
where Q , U, and S are implemented using pure data structures (red-black trees) 
that provide a constant time copy operation. Whenever we need to create a case 
split, we simply create copies of Q, U and S. An alternative approach is to use 
a trail stack [25] which stores operations that “undo” the destructive updates 
performed during the search. We have determined that our simpler approach 
for implementing backtracking is not a bottleneck in our implementation. 

When solving a non-pattern constraint c, the solver creates a case split, and 
stores it on the stack C. Each case split is a tuple of the form ( Q c , U Cl S c ,j a ,j c , z), 
where 

• Qc, U c and S c store the state of the solver when the case split was created, 

• j a is a fresh assumption justification used to track the case split, 
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• j c is the justification for c, and 

• z is a lazy list containing the remaining alternatives, where each alternative 
is a list of constraints. 

We use pull 2 to denote the operation that destructively extracts the head 
of the lazy list z and returns it, or returns none when z is empty. The solver 
catches any error j thrown by the simp procedure, and uses the error resolution 
procedure resolve j defined as follows: 

while C is not empty 

let ( Q c ,U c ,S c ,j a ,j c ,z) = top C in 
if j depends on j a then 

restore state Q := Q c , U := U c , S := S c 

if pull z = some a then visit (a ex j c x j) and return pop C 
failed to solve constraints since C is empty 

In the procedure above, visit (a ix j c ix j) may throw another error j'. If 
this happens it recursively invokes resolve j'. 

3.7 Processing constraints 

At the very core of the algorithm is the procedure for processing the constraints 
in the the queue Q, which we now describe. We use an auxiliary procedure 
process z j, where z is a lazy list of alternatives, and j is a justification. If z 
is empty, it just invokes resolve j. Otherwise, it pulls the head a of z, creates 
a fresh assumption justification j a , pushes the new case split ( Q,U,S,j a ,j c ,z) 
on the stack C, and invokes visit (a ix j a X j). 

For choice constraints (?m t : t in /, j), whether they are ready, regular 
or postponed, we just invoke process (/ (?m l) t S ) j. 

For delta constraints (/ Si... s n ~ / t\ ... t n , j), we try two alternatives. 
In the first one, we assume / is opaque, and try to avoid the potentially ex¬ 
pensive (5-reduction step by using a± = (JILi s i m P ( s i ~ U, j}- If it fails, as 
our next alternative, we unfold / and try 02 = simp((unfold (/ si... s n ) ~ 
unfold (/ t\... t n ), j)). We use the operation tolazy to convert the list \a\, 02 ] 
into a lazy list, and process the delta constraint using process (tolazy [a\, 02 ]) j. 
This case split is a heuristic optimization and is not necessary for completeness. 

The two constraint categories quasi-pattern and flex-rigid are handled in 
the same way; we use different categories only to ensure that easier constraints 
occur first in the priority queue. We undertake an incomplete search for so¬ 
lutions to these constraints using a variation of the flex-rigid case of Huet’s 
unification algorithm m- Given a flex-rigid constraint (?m si... s p ~ t, j), 
the main idea behind Huet’s algorithm is the observation that t must be a term 
of the form / n ... r n , where / is a free variable or a constant. The next idea is 
the observation that any solution for ?m is convertible to one in eta-long normal 
form, which allows us to consider only solutions for ?m that are of the form 

Aaq ...x n ,h (7mi xi... x n )... (?m p x\... x n ) (*) 
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where Irrii are fresh metavariables, and h is a constant or one of the bound 
variables x±... x n . 

In Huet’s algorithm, only opaque constants are considered, so if h is a con¬ 
stant different from / of the rigid term t, the solution would lead to an unsolvable 
constraint. Therefore, we say that Huet’s procedure has two kinds of case splits: 
imitation (when h is the constant / of the rigid term), and projection (when 
h is one of the bound variables x\.. .x n ). However, there are two complica¬ 
tions in our setting. First, we do not eagerly unfold / rq .. .r n when / is a 
constant. For example, assume that sub a b (subtraction for integers) is de¬ 
fined as add a (uminus b). Then (?m (uminus a) rs sub b a, j) has a solution 
?to = Xx , add b x, but we would miss it if we did not unfold sub before trying to 
imitate. Second, we have recursors in our language, and even if / is an opaque 
constant, it is not the only constant that can be used for h. For example, given 
the constraints (7m zero rs true, j), (7m (succ zero) rs false, j), a possible 
solution is 7m = Xx, nat.rec (An, bool) true (Xn r, false) x, where nat.rec 
is the recursor for the type nat (of the natural numbers). We cope with the first 
problem using an approach similar to the one used for delta-constraints when 
/ is a reducible constant. The idea is to have two imitation steps, one where 
/ is not unfolded, and another one where the term / rq ... r n is put into weak 
head normal form before performing the imitation. In our implementation, it is 
currently infeasible to consider the extra imitation step (after whnf) for all con¬ 
stants. Even using non-chronological backtracking, the search space becomes 
too big. The main problem is that the system may spend a huge amount of time 
traversing the whole search space when the user provides an incorrect partial 
construction. As to the second issue, we currently simply ignore this possiblity, 
since the search space would become too big if we considered recursors for h. 
Moreover, if h is a recursor, the constraint obtained after replacing 7m would 
be a stuck recursor. 

As in most higher-order unification procedures, we try first the projection 
case splits because they generate more general solutions. We remark that the 
number of case splits can usually be greatly reduced for quasi-patterns, which 
is the case the arises most commonly in practice. In this case, if / is a con¬ 
stant (not marked as reducible), then we do not need to consider any projec¬ 
tions. Any projection would fail immediately: if we take h to be £i and sub¬ 
stitute (*) for 7m in the original constraint, we obtain an unsolvable constraint 
(£i (?toi t)... (7m p £) r i f n .. .r n , j'). Finally, if f is a free variable i, then 
we only need to consider the projection where h is x, if £i = £. 

For Hex-rigid constraints (7m si...s n w t, j), we only consider the case 
h is Xi when s, is a free variable £, or Si is convertible to t. In the second 
case, where Sj is convertible to t, we simply assign Aaq ■. ■ x n , aq to 7m. This 
is a heuristic for reducing the size of the state, and minimizing the number 
of instances where the procedure exhibits nonterminating behavior. We note 
that in the second-order case, the solver does not miss solutions by using this 
heuristic. Finally, our solver has a threshold on the number of steps that can 
be performed. 

We also use an approximate solution for recursor constraints (t rs s, j). 
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If the head of t and s is the same recursor C.rec, then we try to solve the 
constraint by treating C.rec as a regular opaque constant which has no com¬ 
putational behavior associated with it. If t or s is of the form 1m r , then we 
treat it as a flex-rigid constraint. In a previous implementation of our algo¬ 
rithm, when the recursor C.rec was stuck because of a term ?m r, we tried to 
perform a case split for each constructor C.mk; of C, assigning ?m to terms of 
the form Aa;,C.mk, (?mi x) ... (?m n x). However, this provides only a minor 
improvement on the usability of the system: only three theorems in our library 
broke after we removed this feature, and all of them could be easily fixed by 
providing implicit arguments explicitly. 


4 Related work and conclusions 

The elaboration algorithm we have described above has been developed and 
tuned in conjunction with the development of Lean’s standard and homotopy 
type theory libraries. Although these libraries are still under development, they 
provide ample evidence that the approach we describe here is effective in prac¬ 
tice. At the time of writing, the standard library consists of about 42k lines of 
code, with core datatypes including products, lists, sets, multisets (bags), tu¬ 
ples, subtypes, and vectors; core number systems, namely, the natural numbers, 
integers, rationals, reals, and complex numbers; algebraic structures, including 
orders, (ordered) groups, (ordered) rings, (ordered) fields, and so on; elementary 
finite group theory, through Sylow’s theorem; elementary number theory, such 
as the unique factorization theorem; the beginnings of analysis, including the 
completeness of the reals and elementary properties of limits. The homotopy 
type theory library consists of more than 25k lines of code, including most of 
the first seven chapters of the Homotopy Type Theory book [3U], and a subst- 
natial development of category theory. Specifically, it includes core datatypes 
and constructions, such as paths, fibrations, equivalences, and pathovers; higher 
inductive types, such as the circle, sphere, torus, quotients, pushouts, suspen¬ 
sions; the calculation of the homotopy group of the circle; and category theory 
through the Yoneda lemma. Lean also supported a substantial development in 
nonabelian algebraic topology [33] , carried out by Jakob von Raumer in the 
homotopy type theory framework. 

We attempt to put our work in the context of recent work on elaboration in 
dependent type theories. Abel and Pientka present an extension of Miller-style 
pattern unification [T| which can handle a larger class of problems (in addition to 
E-types) by a method they call pruning, which, intuitively, removes arguments 
to metavariables which fall outside of the Miller pattern fragment, allowing for 
more solutions to be found. They also give a bi-directional inference system for 
a dependently typed A-calculus, which together with the unification algorithm 
yields an outline for a practical implementation. They show the soundness of the 
unification algorithm with respect to this type system. They do not, however, 
treat the case of defined constants, with or without recursion. 

Building upon this is recent work by Ziliani and Sozeau [35] that describes 
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a unification algorithm for the Coq theorem prover which features defined con¬ 
stants and recursively defined functions. They attempt to describe the practical¬ 
ities of such an algorithm for a realistic dependently typed language, outlining 
the heuristics and efficiency compromises inherent in this task. In that respect, 
their motivations are very similar to ours. 

In addition to Abel and Pientka’s pruning, Ziliani and Sozeau add a more 
aggressive form of dependency erasure for metavariables, in an attempt to solve 
more unification problems at the cost of uniqueness of solutions. One example 
is the problem {It true ~ nat, It false ~ nat}. This problem is solved in their 
framework by dropping the dependency of It on its argument, and returning 
the constraint It' « nat which gives the solution It t-> Ax, nat. They also 
add a resolution rule called first order approximation , in which for example the 
constraint ?/ ?y ~ S Ois solved with the assignment ?/>->• S, ?y 0 

Since we have no qualms about allowing multiple solutions and backtracking 
search our algorithms can handle both of these problems easily, in the first 
case by a special case of projection , and in the second by an imitation step. 
Our approach to free variables in metavariables is simple: there are none. In 
contrast, Ziliani and Sozeau carry around a suspended substitution with every 
metavariable, that needs to be managed in each resolution step. The heuristics 
outlined in their paper for unfolding constants are similar to ours: constants are 
unfolded only after an attempt has been made to apply type-class resolution, 
and constants are unfolded to a pattern match or fixpoint only in last resort. 
More study is needed to examine the trade-offs of these various choices. Finally, 
their system does not allow postponement of constraints, relying on pruning 
and dependency erasure to treat most cases up-front. They argue that great 
efficiency gains are obtained in this manner. Again, more study is required to 
assess the trade-offs of this approach. 

Various algebraic developments in Coq make use of type classes E3E3D3I 
and canonical structures mmm-, see also [2] for the use of unification hints 
in Matita. Many of the features we have described are also implemented in 
systems based on simple type theory. For example, Isabelle uses axiomatic 
typeclasses [33] and parameterized contexts (locales) [3] to deal with algebraic 
structures. It also has mechanisms to insert coercions m- The reliance on 
simple type theory, however, makes the elaboration problem quite different from 
ours. For example, an algebraic structure that depends on a parameter, such as 
the integers modulo m, cannot be represented as a type, and so cannot be an 
instance of an axiomatic type class. In contrast to Lean, Isabelle uses different 
languages to construct expressions and assertions, build proofs, and express 
relationships between structures. 

In a different vein, recent work by Brady on the dependently typed language 
Idris describes the elaboration process by analogy with theorem proving (and 
in the context of pure functional programming). Our work is in stark contrast 
with his, as our tactic language is completely disjoint from the methods with 
which we specify the constraint resolution for the unification problems. In Lean, 
the problems are quite different: in unification, metavariables can be very non¬ 
local, appearing in disparate contexts and the solutions can be an infinite stream 
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rather than a simple finite case split. 

To summarize: we have described the elaboration procedure used in the 
new open source interactive theorem prover Lean m- Our procedure uses 
methods found in state-of-the-art constraints solvers, such as nonchronological 
backtracking, indexing, and justification tracking. We have also described how 
coercions, type classes and ad-hoc polymorphism can be smoothly integrated in 
our framework using choice constraints. Our procedure has been tested with the 
development of more than 65k lines of Lean’s formal library, and the experience 
has shown that it provides powerful and effective support for the formalization 
process. 
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